home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc743.txt < prev    next >
Text File  |  1994-08-01  |  16KB  |  472 lines
  1.  
  2. NWG/RFC# 743                                  KLH 30-Dec-77 08:39  42759
  3. Network Working Group                                     K. Harrenstien
  4. Request for Comments: 743                                         SRI-KL
  5. NIC: 42758                                              30 December 1977
  6.  
  7.  
  8.  
  9.                         FTP extension: XRSQ/XRCP
  10.  
  11.  
  12.  
  13.  
  14. This RFC describes an extension to FTP which allows the user of an ITS
  15. FTP server (i.e. on MIT-(AI/ML/MC/DMS)) to mail the text of a message to
  16. several recipients simultaneously; such message transmission is far more
  17. efficient than the current practice of sending the text again and again
  18. for each additional recipient at a site.
  19.  
  20. Within this extension, there are two basic ways of sending a single text
  21. to several recipients.  In one, all recipients are specified first, and
  22. then the text is sent; in the other, the order is reversed and the text
  23. is sent first, followed by the recipients.  Both schemes are necessary
  24. becaue neither by itself is optimal for all systems, as will be
  25. explained later.  To select a particular scheme, the XRSQ command is
  26. used; to specify recipients after a scheme is chosen, XRCP commands are
  27. given; and to furnish text, the usual MAIL or MLFL commands apply.
  28.  
  29. Scheme Selection: XRSQ
  30.  
  31.    XRSQ is the means by which a user program can test for implementation
  32.    of XRSQ/XRCP, select a particular scheme, reset its state thereof,
  33.    and even do some rudimentary negotiation.  Its format is like that of
  34.    the TYPE command, as follows:
  35.  
  36.       XRSQ [<SP> <scheme>] <CRLF>
  37.  
  38.       <scheme> = a single character.  The following are defined:
  39.          R  Recipients first.  If not implemented, T must be.
  40.          T  Text first.  If this is not implemented, R must be.
  41.          ?  Request for preference.  Must always be implemented.
  42.  
  43.          No argument means a "selection" of none of the schemes (the
  44.          default).
  45.  
  46.       Replies:
  47.          200 OK, we'll use specified scheme.
  48.          215 <scheme> This is the scheme I prefer.
  49.          501 I understand XRSQ but can't use that scheme.
  50.          5xx Command unrecognized or unimplemented.
  51.          See Appendix A for more about the choice of reply codes.
  52.  
  53.    Three aspects of XRSQ need to be pointed out here.  The first is that
  54.  
  55.  
  56.  
  57.  
  58.  
  59.                                                                 [Page 1]
  60.  
  61. NWG/RFC# 743                                  KLH 30-Dec-77 08:39  42759
  62. An Extension to FTP
  63.  
  64.  
  65.  
  66.    an XRSQ with no argument must always return a 200 reply and restore
  67.    the default state of having no scheme selected.  Any other reply
  68.    implies that XRSQ and hence XRCP are not understood or cannot be
  69.    performed correctly.
  70.  
  71.    The second is that the use of "?" as a <scheme> asks the FTP server
  72.    to return a 215 reply in which the server specifies a "preferred"
  73.    scheme.  The format of this reply is simple:
  74.  
  75.       215 <SP> <scheme> [<SP> <arbitrary text>] <CRLF>
  76.  
  77.       Any other reply (e.g. 4xx or 5xx) implies that XRSQ and XRCP are
  78.       not implemented, because "?" must always be implemented if XRSQ
  79.       is.
  80.  
  81.    The third important thing about XRSQ is that it always has the side
  82.    effect of resetting all schemes to their initial state.  This reset
  83.    must be done no matter what the reply will be - 200, 215, or 501.
  84.    The actions necessary for a reset will be explained when discussing
  85.    how each scheme actually works.
  86.  
  87. Message Text Specification: MAIL/MLFL
  88.  
  89.    Regardless of which scheme (if any) has been selected, a MAIL or MLFL
  90.    with a non-null argument will behave exactly as before; this
  91.    extension has no effect on them.  However, such normal MAIL/MLFL
  92.    commands do have the same side effect as XRSQ; they "reset" the
  93.    current scheme to its initial state.
  94.  
  95.    It is only when the argument is null (e.g. MAIL<CRLF> or MLFL<CRLF>)
  96.    that the particular scheme being used is important, because rather
  97.    than producing an error (as most servers currently do), the server
  98.    will accept message text for this "null" specification; what it does
  99.    with it depends on which scheme is in effect, and will be described
  100.    in "Scheme Mechanics".
  101.  
  102. Recipient specification: XRCP
  103.  
  104.    In order to specify recipient names and receive some acknowledgement
  105.    (or refusal) for each name, the following new command is also
  106.    defined:
  107.  
  108.       XRCP <SP> <Recipient name> <CRLF>
  109.  
  110.       Reply for no scheme:
  111.          507 No scheme specified yet; use XRSQ.
  112.       Replies for scheme T are identical to those for MAIL/MLFL.
  113.  
  114.  
  115.  
  116.  
  117.  
  118.                                                                 [Page 2]
  119.  
  120. NWG/RFC# 743                                  KLH 30-Dec-77 08:39  42759
  121. An Extension to FTP
  122.  
  123.  
  124.  
  125.       Replies for scheme R (recipients first):
  126.          200 OK, name stored.
  127.          440 Recipient table full, this name not stored.
  128.          450 Recipient name rejected. (Permanent!)
  129.          520 Recipient name rejected.
  130.          4xx Temporary error, try this name again later.
  131.          5xx Permanent error, report to sender.
  132.          See Appendix A for more about the choice of reply codes.
  133.  
  134.    Note that use of this command is an error if no scheme has been
  135.    selected yet; an XRSQ <scheme> must have been given if XRCP is to be
  136.    used.
  137.  
  138. Scheme mechanics: XRSQ R (Recipients first)
  139.  
  140.    In the recipients-first scheme, XRCP is used to specify names which
  141.    the FTP server stores in a list or table.  Normally the reply for
  142.    each XRCP will be either a 200 for acceptance, or a 4xx/5xx code for
  143.    rejection; 450 and all 5xx codes are permanent rejections (e.g. user
  144.    not known) which should be reported to the human sender, whereas 4xx
  145.    codes in general connote some temporary error that may be rectified
  146.    later.  None of the 4xx/5xx replies impinge on previous or succeeding
  147.    XRCP commands, except for 440 which indicates that no further XRCP's
  148.    will succeed unless a message is sent to the already stored
  149.    recipients or a reset is done.
  150.  
  151.    Sending message text to stored recipients is done by giving a MAIL or
  152.    MLFL command with no argument; that is, just MAIL<CRLF> or
  153.    MLFL<CRLF>.  Transmission of the message text is exactly the same as
  154.    for normal MAIL/MLFL; however, a positive acknowledgement at the end
  155.    of transmission means that the message has been sent to ALL
  156.    recipients that were remembered with XRCP, and a failure code means
  157.    that it should be considered to have failed for ALL of these
  158.    specified recipients.  This applies regardless of the actual error
  159.    code; and whether the reply signifies success or failure, all stored
  160.    recipient names are flushed and forgotten - in other words, things
  161.    are reset to their initial state.  This purging of the recipient name
  162.    list must also be done as the "reset" side effect of any use of XRSQ.
  163.  
  164.    A 440 reply to an XRCP can thus be handled by using a MAIL/MLFL to
  165.    specify the message for currently stored recipients, and then sending
  166.    more XRCP's and another MAIL/MLFL, as many times as necessary; for
  167.    example, if a server only had room for 10 names this would result in
  168.    a 50-recipient message being sent 5 times, to 10 different recipients
  169.    each time.
  170.  
  171.    If a user attempts to specify message text (MAIL/MLFL with no
  172.  
  173.  
  174.  
  175.  
  176.  
  177.                                                                 [Page 3]
  178.  
  179. NWG/RFC# 743                                  KLH 30-Dec-77 08:39  42759
  180. An Extension to FTP
  181.  
  182.  
  183.  
  184.    argument) before any successful XRCP's have been given, this should
  185.    be treated exactly as a "normal" MAIL/MLFL with a null recipient
  186.    would be; most servers will return an error of some type, such as
  187.    "450 Null recipient".
  188.  
  189.    See Appendix B for an example using XRSQ R.
  190.  
  191. Scheme mechanics: XRSQ T (Text first)
  192.  
  193.    In the text-first scheme, MAIL/MLFL with no argument is used to
  194.    specify message text, which the server stores away.  Succeeding
  195.    XRCP's are then treated as if they were MAIL/MLFL commands, except
  196.    that none of the text transfer manipulations are done; the stored
  197.    message text is sent to the specified recipient, and a reply code is
  198.    returned identical to that which an actual MAIL/MLFL would invoke.
  199.    (Note ANY 2xx code indicates success.)
  200.  
  201.    The stored message text is not forgotten until the next MAIL/MLFL or
  202.    XRSQ, which will either replace it with new text or flush it
  203.    entirely.  Any use of XRSQ will reset this scheme by flushing stored
  204.    text, as will any use of MAIL/MLFL with a non-null argument.
  205.  
  206.    If an XRCP is seen before any message text has been stored, the user
  207.    in effect is trying to send a null message; some servers might allow
  208.    this, others would return an error code.
  209.  
  210.    See Appendix C for an example using XRSQ T.
  211.  
  212. Why two schemes anyway?
  213.  
  214.    Because neither by itself is optimal for all systems.  XRSQ R allows
  215.    more of a "bulk" mailing, because everything is saved up and then
  216.    mailed simultaneously; this is very useful for systems such as ITS
  217.    where the FTP server does not itself write mail directly, but hands
  218.    it on to a central mailer demon of great power; the more information
  219.    (e.g. recipients) associated with a single "hand-off", the more
  220.    efficiently mail can be delivered.
  221.  
  222.    By contrast, XRSQ T is geared to FTP servers which want to deliver
  223.    mail directly, in one-by-one incremental fashion.  This way they can
  224.    return an individual success/failure reply code for each recipient
  225.    given which may depend on variable file system factors such as
  226.    exceeding disk allocation, mailbox access conflicts, and so forth; if
  227.    they tried to emulate XRSQ R's bulk mailing, they would have to
  228.    ensure that a success reply to the MAIL/MLFL indeed meant that it had
  229.    been delivered to ALL recipients specified - not just some.
  230.  
  231.  
  232.  
  233.  
  234.  
  235.  
  236.                                                                 [Page 4]
  237.  
  238. NWG/RFC# 743                                  KLH 30-Dec-77 08:39  42759
  239. An Extension to FTP
  240.  
  241.  
  242.  
  243. Stray notes:
  244.  
  245.    * Because this is after all an extension of FTP protocol, one must be
  246.    prepared to deal with sites which don't recognize either XRSQ or
  247.    XRCP.  "XRSQ" and "XRSQ ?" are explicitly designed as tests to see
  248.    whether either scheme is implemented; XRCP is not, and a failure
  249.    return of the "unimplemented" variety could be confused with "No
  250.    scheme selected yet", or even with "Recipient unknown".  Be safe, be
  251.    sure, use XRSQ!
  252.  
  253.    * There is no way to indicate in a positive response to "XRSQ ?" that
  254.    the preferred "scheme" for a server is that of the default state;
  255.    i.e. none of the multi-recipient schemes.  The rationale is that in
  256.    this case, it would be pointless to implement XRSQ/XRCP at all, and
  257.    the response would therefore be negative.
  258.  
  259.    * One reason that the use of MAIL/MLFL is restricted to null
  260.    arguments with this multi-recipient extension is the ambiguity that
  261.    would result if a non-null argument were allowed; for example, if
  262.    XRSQ R was in effect and some XRCP's had been given, and a MAIL
  263.    FOO<CRLF> was done, there would be no way to distinguish a failure
  264.    reply for mailbox "FOO" from a global failure for all recipients
  265.    specified.  A similar situation exists for XRSQ T; it would not be
  266.    clear whether the text was stored and the mailbox failed, or vice
  267.    versa, or both.
  268.  
  269.    * "Resets" are done by all XRSQ's and "normal" MAIL/MLFL's to avoid
  270.    confusion and overly complicated implementation.  The XRSQ command
  271.    implies a change or uncertainty of status, and the latter commands
  272.    would otherwise have to use some independent mechanisms to avoid
  273.    clobbering the data bases (e.g. message text storage area) used by
  274.    the T/R schemes.  However, once a scheme is selected, it remains "in
  275.    effect" just as a "TYPE A" or "BYTE 8" remains selected.  The
  276.    recommended way for doing a reset, without changing the current
  277.    selection, is with "XRSQ ?".  Remember that "XRSQ" alone reverts to
  278.    the no-scheme state.
  279.  
  280.    * It is permissible to intersperse other FTP commands among the
  281.    XRSQ/XRCP/MAIL sequences.
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294.  
  295.                                                                 [Page 5]
  296.  
  297. NWG/RFC# 743                                  KLH 30-Dec-77 08:39  42759
  298. Appendix A - on FTP reply codes
  299.  
  300.  
  301.  
  302.                            On FTP reply codes
  303.  
  304.    The choice of appropriate reply codes for new or experimental
  305.    commands is difficult because there have been three possible
  306.    "official" sets of codes which one may draw on, and it is not clear
  307.    which of them might be in use at any particular site; these are (1)
  308.    Old FTP, (2) New FTP, (3) Revised New FTP.  In my choice of code
  309.    assignments, I have for the most part ignored these and used RFC 691,
  310.    "One More Try on the FTP", by Brian Harvey.  My motivation for this
  311.    is the simple observation that I know of no site which implements
  312.    "new FTP", and RFC 691 incorporates much of the "new FTP" reply code
  313.    logic into the framework of "old FTP".  The only sharp conflict is
  314.    treated by allowing 450 to have its "old" meaning, equivalent to 520
  315.    - permanent failure.  Note that when testing to see whether a site
  316.    understands a FTP command, a reply of 5xx (specifically, 500) will
  317.    generally indicate, for all sets of codes, that the command is
  318.    unrecognized.
  319.  
  320.    By the way, I recommend RFC 691 as required reading for FTP
  321.    implementors; maybe if enough people get together this mess can be
  322.    straightened out.
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349.  
  350.  
  351.  
  352.  
  353.  
  354.                                                                 [Page 6]
  355.  
  356. NWG/RFC# 743                                  KLH 30-Dec-77 08:39  42759
  357. Appendix B - Example of XRSQ R
  358.  
  359.  
  360.  
  361.                   Example of XRSQ R (Recipients first)
  362.  
  363.    This is an example of how XRSQ R is used; first the user must
  364.    establish that the server in fact implements XRSQ:
  365.  
  366.       U: XRSQ
  367.       S: 200 OK, no scheme selected.
  368.  
  369.    An XRSQ with a null argument always returns a 200 if implemented,
  370.    selecting the "scheme" of null, i.e. none of them.  If XRSQ were not
  371.    implemented, a code of 4xx or 5xx would be returned.
  372.  
  373.       U: XRSQ R
  374.       S: 200 OK, using that scheme
  375.  
  376.    All's well; now the recipients can be specified.
  377.  
  378.       U: XRCP Foo
  379.       S: 200 OK
  380.  
  381.       U: XRCP Raboof
  382.       S: 520 Who's that?  No such user here.
  383.  
  384.       U: XRCP bar
  385.       S: 200 OK
  386.  
  387.    Well, two out of three ain't bad.  Note that the demise of "Raboof"
  388.    has no effect on the storage of "Foo" or "bar".  Now to furnish the
  389.    message text, by giving a MAIL or MLFL with no argument:
  390.  
  391.       U: MAIL
  392.       S: 350 Type mail, ended by <CRLF>.<CRLF>
  393.       U: Blah blah blah blah....etc etc etc
  394.       U: .
  395.       S: 256 Mail sent.
  396.  
  397.    The text has now been sent to both "Foo" and "bar".
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413.                                                                 [Page 7]
  414.  
  415. NWG/RFC# 743                                  KLH 30-Dec-77 08:39  42759
  416. Appendix C - Example of XRSQ T
  417.  
  418.  
  419.  
  420.                      Example of XRSQ T (Text first)
  421.  
  422.    Using the same message as the previous example:
  423.  
  424.       U: XRSQ ?
  425.       S: 215 T Text first, please.
  426.  
  427.    XRSQ is indeed implemented, and the server says that it prefers "T",
  428.    but that needn't stop the user from trying something else:
  429.  
  430.       U: XRSQ R
  431.       S: 501 Sorry, I really can't do that.
  432.  
  433.    Oh well.  It's possible that it could have understood "R" also, but
  434.    in general it's best to use the "preferred" scheme, since the server
  435.    knows which is most efficient for its particular site.  Anyway:
  436.  
  437.       U: XRSQ T
  438.       S: 200 OK, using that scheme.
  439.  
  440.    Scheme "T" is now selected, and the text must be sent:
  441.  
  442.       U: MAIL
  443.       S: 350 Type mail, ended by <CRLF>.<CRLF>
  444.       U: Blah blah blah blah....etc etc etc
  445.       U: .
  446.       S: 256 Mail stored.
  447.  
  448.    Now recipients can be specified:
  449.  
  450.       U: XRCP Foo
  451.       S: 256 Stored mail sent.
  452.  
  453.       U: XRCP Raboof
  454.       S: 520 Who's that?  No such user here.
  455.  
  456.       U: XRCP bar
  457.       S: 256 Stored mail sent.
  458.  
  459.    Again, the text has now been sent to both "Foo" and "bar", and still
  460.    remains stored.  A new message can be sent with another MAIL/XRCP...
  461.    sequence, but the fastidious or paranoid could chose to do:
  462.  
  463.       U: XRSQ ?
  464.       S: 215 T Text first, please.
  465.  
  466.    Which resets things without altering the scheme in effect.
  467.  
  468.  
  469.  
  470.  
  471.  
  472.                                                                 [Page 8]